Over the last decade, cellular carriers have developed an increasing number of services to support mobile applications. For example, these services include, e.g., mobile presence services, location-based services, multimedia messaging service (MMS), short message service (SMS) messaging, etc. These services have traditionally been accessed by very well-defined carrier-supported services.
In the last few years, enterprises have implemented various methods for developing and deploying mobile applications. In order to facilitate the development and implementation of mobile applications and communication with enterprises to provide access to these services by enterprises, carriers have implemented specialized gateways with Application Programming Interfaces (APIs) that provide a front-end to these services. These gateways, which are referred to as carrier API gateways, allow enterprises to issue requests using high-level languages and parameters (HLLAPIs) and low-level language procedural calls (LLAPIs). Once requests from enterprises are received by the carrier API gateways, the carrier API gateways then issue complex and secure commands for various carrier-based services, such as presence services, location services, multimedia messaging service (MMS), short message service (SMS), etc. This information is then relayed back to the requesting enterprise using high-level APIs or low-level APIs. The benefit of this approach is that enterprises supporting mobile applications only have to interface with one API gateway for each carrier, as opposed to making multiple calls for location services, presence services, MMS, SMS, and other carrier services.
While carrier API gateways simplify the interface to enterprises for providing application services to mobile communication devices, the reality is that enterprises are seldom, if ever, served by a single carrier. Most enterprises utilize at least two carriers and often have three or four carriers supporting their mobile applications.
Currently, enterprise servers have to interface with a different carrier API gateway for each carrier with which they contract, resulting in a requirement to interface through a plurality of carrier API gateways for a plurality of contracted carriers. This may be understood with reference to FIG. 1.
Referring to FIG. 1, an enterprise web and application server 110 (referred to hereafter as an “enterprise server”) interfaces with carrier 1 API Gateway 120A for providing application services for mobile communication devices 140A and 140B associated with carrier 1 networks 130A. Similarly, the enterprise server 110 interfaces with carrier 2 API Gateway 120B for application services for mobile communication devices 140C and 140D associated with carrier 2 networks 130B. The enterprise server 110 communicates with the carrier API gateways 120A and 120B via a communication network 115, such as the Internet. The carrier API gateway 120A is dedicated to carrier 1, and the carrier API gateway 120B is dedicated to carrier 2.
Requests from and responses to the enterprise server 110 that are associated with carrier 1 are communicated via the Internet 115, the carrier 1 API gateway 120A and the carrier 1 networks 130A. Similarly, requests from and responses to the enterprise server 110 that are associated with carrier 2 are communicated via the Internet 115, the carrier 2 API gateway 120B and the carrier 2 networks 130B.
Carrier 1 API gateway 120A and the carrier 2 API gateway 120B typically have inconsistent communication protocols. Thus, the enterprise server 110 must issue requests and interpret responses differently for each carrier API gateway.
As the number of application services grows, interfacing with different carrier API gateways becomes cumbersome and inefficient. Furthermore, if any given carrier has not implemented an API gateway, the enterprise server 110 must then interface directly, in a rudimentary fashion, with a plurality of single-threaded services for smaller carriers.